In a common distributed Device Management System (DMS), the system functions are distributed over server and client machines, which typically are remote from each other. To support device management in workshop scenarios or on mobile clients in the field, communication devices such as HART FSK modems are required alongside the client machines, i.e. also remote from the server. HART (Highway Addressable Remote Transducer refers to a digital industrial automation protocol for the digital communication of in particular field devices in a plant automation site.
If DMS functions such as device-specific business logic or support for nested communication are hosted on the server or server machine, the client-side communication devices and the server-side functions must be integrated with each other, preferably in an easy and robust manner.
The approaches from classic device integration technologies such as FDT (Field Device Tool) cannot be applied anymore, and next-generation technologies such as FDI (Field Device Integration) do not specify technical solutions for this situation.
Field Devices, like in particular metering devices, sensors, valves or drives or actuators, are an integral part of any Distributed Control System (DCS). They perform the sensing and actuation functions which the DCS requires to have any notion or conception of the state of the process to control. Without field devices, the DCS would basically be blind and incapable of any action. These field devices must be parameterized, commissioned, and their health and operation condition has to be monitored during the operation of the plant. For this task device tools with knowledge and/or capabilities of a specific communication technology, device, or family of devices are used. These tools are either implemented as stand-alone software components to directly communicate with each physical device or as modular integration components.
A Device Management System (DMS) can be regarded as a framework into which these integration components can be integrated. The DMS offers and/or requires defined functions to or from the integrated tools in order to provide system-level functions beyond the means of each individual tool. This may include the representation of the physical field topology and the integration of all tool-supplied user interfaces.
A main function or object of a DMS is to provide data access from the individual device tools to their belonging or corresponding field devices via a hierarchical communication infrastructure.
A state-of-the-art DMS architecture provides integration components for devices, containing device-specific know-how for parameterization and diagnosis, and gateways, translating between protocols, and are realized in a modular manner. Communication traverses a hierarchy of nested gateway tools corresponding to the field topology of gateway devices which may be none or many. The transition between the DMS data structures and the physical world may be realized via dedicated communication tools which have hardware access to the first physical interface in the communication hierarchy.
In a distributed DMS, device, gateway, and communication tools may be hosted within multiple client and server data structures and/or software components.
Typically, there will be a single server, in particular a redundant server arrangement. For large systems, multiple servers may be introduced but each server is assigned only to a partition or part of the field topology
In a distributed DMS, executable client and server data structures may be deployed to client and server machines. The communication tools may even be implemented directly on or applied to the communication devices.
In a stand-alone or single-node DMS, all client and server functions may even be deployed to a single machine. Particularly for Ethernet communication, a communication device may also be hosted within the server machine.
Unfortunately, in any real system, like for example when using an FDI DMS, the client and server functions have to be deployed onto runtime machines. Using e.g. an FDI DMS, these situations arise:
In distributed deployment scenarios where all communication devices are connected to the FDI server, nested communication can occur in straight-forward manner; the FDI communication servers are installed on the same machine as the FDI server and a communication manager is provided which determines the communication path by analyzing the FDI Information Model. In particular, the FDI server ensures and provides that the communication devices, representing critical resources, can be shared between all users/clients.
The same holds or applies for single-node systems where all functions reside on the same machine.
However, a typical workshop scenario requires the communication devices to be available at the client machines where the physical devices are also located. These clients may be stationary or may be mobile, temporarily available machines.
In conclusion, the locally attached communication devices may only be available temporarily or at least may be “owned” by the connecting client—they should exactly not be shared between other clients on other client machines and other users. They connect to devices which are or will be engineered as part of an “operative” field topology but at the time are accessed through a separate, temporary connection. It appears inefficient and unnecessary to explicitly engineer a second, “non-operative” topology for temporary use.
Furthermore, this means that also the connected devices are only reachable via the local communication device temporarily.
Connecting the communication devices locally and still installing the corresponding communication servers on the FDI server seems to be no satisfying and advisable solution for several reasons:
For HART, PROFIBUS, Foundation Fieldbus HART serial or USB modems, etc., access to local hardware is required; this is exactly the reason why the FDI standard proclaims communication servers as separate entities which may include binary code to access hardware outside of the EDD (Electronic Device Description) engine. In this sense, having a communication server remote from the client is even technically impossible.
In a distributed (multi-node) FDI system, where FDI client and FDI server reside on at least two different machines, bypassing the FDI server for communication is not advisable, either:
To achieve nested communication along a path in the topology, the Communication Manager residing on the FDI server must have knowledge of and access to the distributed communication servers on the client machines. As a device description may also include business logic for download, circumventing the FDI communication mechanisms entirely from the client is not possible, either; the content of the communication must be controlled from within the EDD engine, which also resides on the server.
For industrial Ethernet protocols, running IP or Ethernet communication in parallel to the client would mean running (possibly not even routable) fieldbus traffic within the engineering network.
Accordingly, a solution is required which allows client-side communication servers and their communication devices to be made available easily to the communication manager within the FDI server, in particular deployed on a separate, remote server machine to increase network efficiency and quality and/or data transfer capacity. This has to be done in a manner that the temporary nature and ownership of the communication devices can be taken into account by the respective communication manager.
Thus all communication devices and their servers must be registered centrally with the FDI server. This leads to a situation where a communication server on one client could be accessed by a transaction (such as a download) triggered on another client. This appears inefficient and leads to lower usability for the end user.
Simply duplicating an entire FDI system on the client does not solve this issue. Firstly, all engineering data must still be synchronized with the main FDI server, which is also expected to have the current and valid engineering data stored; FDI provides no immediate solution to keep several servers synchronized automatically and reliably. Secondly, this does not resolve the problem of having multiple temporary communication topologies.
At that time no efficient technical solution for this is provided by the FDI standard draft, and the draft status of the standard naturally prohibits any product to already exist.